So you're looking to work on some code and want ot know how you can use git to track the progress of development in a reasonable way? Here's a quick outline of what might be required over a standard set of changes to a co
Firstly we'll need a repo to work on, I'll assume you know what you want to work on here and have a cloud/remote repo that holds the co
# SSH connection format workspace$ git clone firstname.lastname@example.org:UserName/projectRepo.git # HTTP connection format workspace$ git clone https://UserName@bitbucket.org/UserName/projectRepo.git
If you've just created your respo by using the above then you won't need to perform this step but to ensure that the info your local repo holds the latest information from your remote run this command, it will ensure that when the tracking branch is created it is created with the latest information.
git pull origin master
Now that you've got a version of the repository locally you'll be in the default branch initially whish is usually 'master'. It's good practice to separate out each change or set of changes into their own branch.
# Create a branch locally called 'dev' that tracks the current branch git checkout -b dev # As above, create a local branch but this pulls from the branch 'dev' on origin and has the upstream set git checkout -b dev origin/dev
If the project you're working on (or branch if you've just grabbed one from origin) has submodules you'll need to make sure that you've got them initialised. Fortunately as with a lot of git, the series of commands that you'd need to enter to do this can be rolled into the below
git submodule update --init --recursive
One of the really nice things about git is that it lets you store your code in chunks and track the progress of those chunks, if however you want to use one of those chunks in a new solution then submodules are what you need and as you're basically pulling a new git repo into your current one the syntax is very similar to the initial cloning commands above.
# SSH connection submodule addition git submodule add email@example.com:UserName/projectRepo.git # HTTP connection submodule addition git submodule add https://UserName@bitbucket.org/UserName/projectRepo.git
when you've made changes to files in your branch git will initially hold these as 'Unstaged Changes'. To commit these changes you will need to 'stage' them beforehand, to take a look at what's happening here run the familiar favourite Git Status. on doing that you'll see the status of each file that git is aware of a change for and whether each change has been staged:
- Git Status -w- output
You can stage files in either of the following two ways, hit git status again to show that your files are staged.
git add [filepath]
git add .
- The second of these commands will add -everything- so be careful with it's use if your .gitignore file isn't up to scratch or you've got files which you'd rather not track as part of your work - in that instance it's much easier to add something to tracking than it is to remove
- Git add ., git add "", git status
to revert changes or remove a file from being staged try these or take a look here:
- git reset, git checkout previous etc..
Once you've got all of your files properly staged or reverted then commit your changes to your local repo using the following. Make sure that the message that you include is useful, it'll really help if you need to isolate specific changes later.
git commit -m "message"
git commit -m "update of sql generation classes to include proper IN handling"
At this point your changes are sat, commited to your local repository, now you need to get them to the remote for the rest of the process to continue. Depending on your security setup it's entirely possible that you can't simply push back to the remote branch that you based your branch on, a common setup is for these updates to be managed via 'pull requests'. Before you push anything it's worth taking a look to see which branches you have and what the upstream branch is for each of them (the remote branch to which your local branches refer). The command for this is simply:
- git branch -a -vv
If you haven't pushed this change set before then the upstream on your current branch will still be
# git push [remoteName] [branchName] git push -u origin thisbranch # git push [remoteName] [branchName]:[newRemoteBranchName] git push -u origin thisbranch:newbranchname
As mentioned above, if there have been changes to the initial repository in the period of time that you've had your branch then you'll need to resolve any merge conflicts. To do this simply pull from the branch that you're trying to merge into and fix any conflicts that arise. Your most recent commit is still there so if you want to outright overwrite a file that's been amended in both the remote and your local repository you can use the same line as above:
git remote prune origin