This gist provides a list of git configuration and git cli commands for certain common tasks and for the Git Workflow adopted for this project. GitHub Desktop is widely used but UI of git gui and Tortoise Git could be familiar for Tortoise Hg users.
.gitconfig is the equivalent of hg settings.
- user-specific settings
git config --global user.name "John Doe"
git config --global user.email johndoe@example.com
# to handle long file paths
git config --system core.longpaths true
# To view the list of global config
git config --list --show-origin
# Need to set the default editor for use with Rebase
git config --global core.editor "c:\\<<path_to_editor>>"Open command window from the folder where the local repo will be setup
git clone <<http-url>>this will automatically create a remote entry named 'origin'. To get list of all branches, create a feature branch from 'develop' branch
git branch --all
git checkout -b <<your_feature>> develop This will change the 'working branch' to the above created branch. At any point in time, if you want to see what is the working branch, do git branch and this will list all the branches with '*' next to the working branch.
The Mobify release deployment was referred for this section.
- Get the latest for develop from remote
- create your feature branch off the develop
- set upstream branch in remote (this is needed as the develop branch would be protected). Only way to merge your changes would be to create pull request from your
remotefeature branch. - Any new files created needs to be added first so that it will be indexed.
git pull origin develop
git checkout -b <<feature_branch>> develop
git branch -u origin <<feature_branch>>
git add <<path_to_new_file(s)>>Suggested practice is to not commit till the change is tested, even in local repository & feature branch. Once the feature is completed and ready to push the commits to remote branch, if possible, try to compress/fine tune the commit history before pushing. This helps in avoiding the clutter in the 'develop' and 'master' branches. git rebase lets this possible.
Steps to rebase are:
- View the commit history and note down the
commit idbefore the feature was started.
$ git log --oneline
# to rebase commits since 414e335c above,
$ git rebase -i HEAD~4this will open the selected log entries in the editor configured. The commit ids are presented in ascending order from HEAD~4 in this example. To pick only one commit in the history and squash 3 other commits, combine the chages to the picked commit, the changes will be done as shown below.
Assuming the push to develop branch requires a pull request, the only option available is to push the feature branch upstream.
If the branch is not available in the remote, issue
$ git push -u origin <<feature_branch>>if the branch is already available, make sure to pull from remote before a push
$ git pull origin <<feature_branch>>
$ git push origin <<feature_branch>>If there is a conflict and auto-merge fails, the impacted file will be flagged. The conflict needs to be resolved manually.
The changes in the local (ours) will be marked with <<<<< HEAD ending with ======, the changes in the remote(theirs) will be marked with `>>>>> COMMIT_ID. A sample is shown below.
Once resolved, need to add the file explicitly
$ git add <<complete_path_to_the_conflict_resolved_file>>Once the feature branch changes are pushed to remote branch, need to create a pull request to merge those commits to the develop branch. The following can be done through WEB UI as well.
Note: please refer Distributed GIT for detailed escription of possible workflows. Here we use one of the asuggested approach
Steps to follow:
1. Checkout to develop branch and get the details of the HEAD/latest commitid from the develop branch.
2. Get the commit details available in the feature branch that are available since the HEAD commit in develop
3. Reviewer will then pull the changes from the remote repo
git request-pull 2f2e3c1 https://github.aig.net/<<origin-branch>> featureA
Reviewer can then merge the feature branch to the
develop branch, preferrebly either using --no-ff or by using rebase.
Note: Please always start checkout from develop when working on multiple features. This will be helpful if and when a changeset needs to be pulled out.