Git-Pane
We already saw that how to Create a Repository on GitHub and also how to Clone a Project/Repository from GitHub. Now, once a repository is on WebIDE, development, and collaboration starts. To achieve effective collaboration, to keep a single source of truth, syncing is required with GitHub and other stakeholders. Git Pane in WebIDE enables us to do this.
This is Git Pane and this pretty much does everything Git framework needs to do from Git client perspective.
Diagram 1
Git Pane can be accessed by clicking Git Icon in right side pane. Alternatively, it can also be accessed by Menu > View > Git Pane.
Let’s discuss features one by one, one at a time!
- Repository: This is one of the most basic attributes of Git Pane and stays on the top. This gives information about the repository name on GitHub.
- Branch: A repository has an initial main branch called ‘master’ where all the development files and folders are kept. Initial design and development are, however, subject to change with the time for bug resolutions, change requests and new features. For working with new features, it is recommended to work on new version of the code and preserve the backup of old code. Branch does the same as another branch is opened with a feature specific name and changes are done under that new branch. This preserves the old code as a snapshot and changes are carried out under the new branch.
- Create Local branch/Delete branch: Create and Delete branch action can be carried out with Plus and Minus signs in front of Branch drop-down. To carry out changes in an established branch, a new local branch can be created. This effectively preserves the good old code. Local branch can be further replicated to the remote branch. In the same way, a branch can be deleted from within the Git Pane as and when required.
- Pull: If any point in time, some other team member changes in Project code, the code in WebIDE become obsolete. To sync the code, a pull request is initiated from the Git Pane. This imports the changes to the selected branch. Pull works very similar to combination of Fetch followed by Rebase though they are different.
- Fetch: Fetch request syncs Project’s local metadata with GitHub’s data. In other words, if the project in WebIDE is not identical with GitHub, a fetch request provides a confirmation of same to the user. Fetch also updates the local project with the information that what is changed or missing! Fetch doesn’t actually replicates the changes from GitHub to local WebIDE.
- Rebase: After a fetch request, WebIDE becomes aware if local WebIDE and GitHub are out of sync. Rebase operation replicates the changes to the local WebIDE project. Rebase may give a warning if the same file is modified by two developers and also allows to patch it. With the rebase command, Developer can take all the changes that were committed on one branch and replay them on another one.
- Merge: Merge operation allows to merge the active branch with another local/remote branch of developer’s choice.
- Reset: This allows to reset the project with respect to specified branch by the user. This has two types:
- Mixed – Mixed reset gives the option to make flexible changes. Mixed Reset is carried out on Head and Index.
- Hard – Hard reset is carried out on Head, Index and working directory. Everything from source branch is replicated to active branch.
- Staging: There is a dedicated table called staging table for Staging. Staging marks the objects for commit. There may be the case that if changes were on multiple files but commit is required on only a few identified files and staging gives the option to mark the files to be committed.
- Commit Description: This should be always maintained for the reason for commit. This is mandatory for Commit/Commit and Push operations. If ‘Amend changes’ is selected, Commit description is automatically fetched from the last commit.
- Amend Changes: It is a good practice to regularly commit local changes similar to the “Save” we do in any programming language. If we do commit to the same Project, again and again, it is good to mark “Amend Changes” as it creates a single snapshot to be Pushed to GitHub.
- Commit: Commit creates a snapshot to be pushed to GitHub for synchronization. This also removes staged files and adds them to the same snapshot.
- Push: Push replicates the Commit snapshot to GitHub. Push operation may give an error in case of discrepancy.
- Commit and Push: This button does Commit as well as Push in one shot. If any error is expected during this process, it is suggested to do Commit and Push separately as it gives a better idea of error tracing.
- Git History: Git History provides the option to compare changes in common files of two versions. This offers a familiar split pane look and feel of ABAP version comparison of source code.
Diagram 2 - Stash: If Show stash button is disabled, changes are appearing in the staging table, the developer doesn’t wish to commit changes and save this snapshot to be used later than Stash option is a just perfect use case.
- When Stash button is clicked, Git Pane informs the developer that current changes will be stashed in a virtual history Stack and the last working copy will be retrieved.
Diagram 3 - Also, An optional message can be added describing stashed information or an automatic ID is created. Never miss a chance to add a user message to Stash creation dialog as it helps later during Stash retrieval process. It is also important because more than one Stash can be created and during retrieval, user message helps to identify right stash to retrieve.
- Once Stash(es) is(are) created, ‘Show Stash’ button becomes active. There can be many stashes and all are stored in a ‘Stack’ data array type.
- When Stash button is clicked, Git Pane informs the developer that current changes will be stashed in a virtual history Stack and the last working copy will be retrieved.
- Show Stash: Show Stash button in Git Pane retrieves Stash(if any exists else this button stays inactive) and ask the user for any one of below actions:
- Apply – Apply copies changes from top Stack element and replicates it back to the Project. The stack will still contain Top element after Apply operation. Refer diagram 3 for before Apply operation.
Diagram 4 - Pop – Pop cuts changes from top Stack element and replicates it back to the Project. The Top element will be deleted after the Pop operation. Refer diagram 3 for before Pop operation.
Diagram 5 - Drop – Drop deletes topmost Stack element. This allows next Stash for Apply or Pop or Drop operation. Drop operation doesn’t impact Project in any way. Refer diagram 3 for before Drop operation.
Diagram 6 - Cancel – Cancel terminates current operation and no action is carried on Stash stack.
- Apply – Apply copies changes from top Stack element and replicates it back to the Project. The stack will still contain Top element after Apply operation. Refer diagram 3 for before Apply operation.